昨天 Day 01，我們訂下本次鐵人賽的目標：
用 30 天，把 Google AI 生態系摸一遍，最後做出一個自己真的會用的 Coding 小幫手。
既然目標都訂了，今天照理我們應該馬上開始玩 Gemini。
但我決定先踩煞車。
因為對第一次接觸 Gemini API 的人來說，我覺得有一件事情比「怎麼呼叫 AI」更重要：
我到底會不會不小心花到錢？
而且 API Key 如果亂放，萬一哪天不小心推上 GitHub，好像也不是一句「抱歉我忘了」就能解決。
所以 Day 02 不寫程式。
今天先把「錢包、專案、API Key」這三件事情搞清楚。
如果是第一次接觸 Gemini API，很容易把它想成：
Google AI Studio → 拿 API Key → 免費一直呼叫。
但實際上沒有這麼單純。
Gemini API 有自己的使用限制，常見的限制包含：
而且這些限制是以 Project 為單位，不是每一把 API Key 各自計算。
更重要的是，限制會跟使用的模型與目前的使用層級有關，所以今天查到的數字，未來不一定還是一樣。Google 官方也明確提醒，實際可用容量不一定完全等於頁面列出的限制。
所以這次我不打算在文章裡硬背一個「每天幾次」的數字。
我的做法是：
需要用多少，就進 AI Studio 看當下 Project 的實際 Quota。
這樣反而比較不容易把過時資訊當成規則。
這三個名詞是今天最大的學習重點。
我目前會用一個很簡單的方式理解：
Project = 房間
API Key = 房間的鑰匙
Quota = 房間每天能用多少水電
所以 API Key 不是獨立存在的。
Google 官方文件說明，每一個 Gemini API Key 都會和 Google Cloud Project 關聯，而 Gemini API 的 rate limits 是套用在 Project 上。
這也代表：
如果我在同一個 Project 裡建立兩把 API Key，
不是兩把 Key 就有倆份 Quota。
這個觀念先搞懂，後面碰到 API 串接時會輕鬆很多。
圖 1｜Google AI Studio 的 API Keys 頁面
這裡可以查看目前有哪些 API Key，以及每把 Key 所屬的 Project。現在新建立的 API Key 預設會使用 Google 推薦的新驗證金鑰機制。
我們可以透過右上角的Create API key來創建Project和生成API key。
Google 官方目前正在從 Standard API Key 遷移到 Authorization Key，而且 2026 年 9 月起，未完成處理的 Standard Key 會面臨 API 拒絕要求的限制。因此，如果你看到「Key Type」欄位，不要把它當成無關緊要的小資訊。
看到「Google Cloud」四個字，很多人第一個反應可能是：
「等等，我是不是要先綁信用卡？」
這也是我今天最想確認的一件事。
目前 Gemini API 的帳戶會從 Free Tier 開始。Google 官方文件也把 Free Tier 與付費 Tier 分開說明。
如果要升級到 Paid Tier，才需要設定並連結 Cloud Billing；官方目前的流程也包含設定付款方式與付費帳務。
所以我的學習策略很單純：
目前只是學習與做小型實驗，就先留在 Free Tier。
不需要為了「感覺比較專業」就急著開 Billing。
圖 2｜確認目前使用的 Project 是否仍在 Free Tier
開始實驗前，先確認自己使用的是哪個 Project，以及目前的 Billing 狀態。對目前只是學習 Gemini API 的階段來說，先維持 Free Tier，就可以降低誤開付費功能的風險。
這裡還有一個現在很值得注意的新規則：
不要把「Google Cloud 免費試用」和「Gemini API 免費方案」混為一談。
Google 官方目前已說明，從 2026 年 3 月開始，Gemini API 使用成本不包含在 Google Cloud 的 $300 Free Trial 裡。
所以看到「免費」兩個字，還是要先看清楚它是哪一種免費。
再進行後續的設定之前，有件事情非常重要，重要到必須說三遍。
API Key 要當成密碼。
API Key 要當成密碼。
API Key 要當成密碼。
因為只要別人取得你的 Key，就可以任意的拿你的 Project 資源來發送 API Request(就像小偷拿到了你家的鑰匙)。
Google 官方也直接把 API Key 視為敏感資訊，並提醒：
而官方建議的基本做法，就是使用環境變數。
我們先假設未來的 DevPulse 專案長這樣：
devpulse/
├─ .env
├─ .gitignore
├─ package.json
└─ index.js
我的 API Key 就放在：
GEMINI_API_KEY=我的API金鑰
而 .gitignore(.gitignore 檔案是用來告訴 Git 哪些檔案或目錄不需要被版本控制追蹤的設定清單)：
.env
這樣至少先把最容易犯的錯誤擋掉。
.env
圖 3｜將 API Key 放入環境變數
Key 是機密資訊，不應直接寫死在程式碼裡。這次先透過
.env保存，讓後面的 Node.js 程式透過環境變數讀取。
光建立 .env 還不夠。
因為如果 Git 仍然追蹤 .env，最後還是可能把它一起 Push 上 GitHub。
所以我今天順便確認：
git status
看看 .env 有沒有出現在待提交檔案裡。
如果設定正確，應該不會看到它。
圖 4｜確認 Git 沒有追蹤
.envAPI Key 的安全並不是「放到
.env」就結束了，還要確認.env真的被.gitignore排除。
這個步驟很小，但我覺得非常重要。
因為很多人真正出問題的地方，不是「不知道 API Key 要保密」，而是：
知道，但是不小心 commit 出去了。
這也是我今天一直在想的問題。
原本的規劃是採用「雙專案防禦策略」，把實驗環境與其他用途分開。
我現在比較傾向把它理解成：
不要把實驗用 Project 和未來正式使用的 Project 混在一起。
但是對Day 02 的階段來說還不需要瘋狂建立一堆 Project。
目前只要先做到：
這是一個單純拿來學習 Google AI 的 Project。
未來真的開始做 DevPulse 正式版本，再考慮怎麼切分環境就好。
這樣才不會為了「資安最佳實務」反而把環境搞得太複雜。
今天最後一個動作，就是回 AI Studio 看一下目前的使用限制。
這裡我不想記數字。
因為 Google 官方已經明確說明，API rate limits 會依模型與使用層級變動，而且實際容量也可能與標示值不同。
所以今天我們要學會的不是：
「Gemini 每天可以呼叫幾次？」
而是：
「我要去哪裡確認 Gemini 現在可以呼叫多少？」
這兩件事情差很多。
圖 6｜查看目前 Project 的 Gemini API 使用情況
這裡可以觀察目前的 API 使用量與相關限制。由於不同模型與使用層級的限制可能不同，因此實際數值以當下 AI Studio 顯示為準。
Google 官方也提供 AI Studio 的 Dashboard → Usage 來查看 Gemini API 的使用情況。
做到這裡，我今天沒有叫 Gemini 幫我生成任何程式。
但我反而覺得這一步很重要。
因為昨天的我只知道：
「我要用 Gemini API 做 Coding Assistant。」
今天開始，我們已經有以下的觀念：
Project
↓
API Key
↓
Quota
↓
程式透過環境變數取得 Key
↓
Git 不提交 .env
這條線先建立起來。
接下來 Day 03，才是真的把 Google AI Studio 打開，看看這個「AI 實驗室」到底可以玩什麼。
今天完成：
.env
.env 加入 .gitignore
git status 確認沒有追蹤 .env
原本我規劃今天的主題應該是「怎麼取得 Gemini API Key」。
但後面想想，只是取得Key並不是重點，真正重要的是
這把 Key 到底屬於誰？
Project 是環境，API Key 是通行證，而 Quota 則是這個環境目前能使用多少資源。
先把這些基礎觀念建立起來，後面開始寫 API 時，就不會只是在盲目的把一串亂碼填入程式之中。
Day 03，再來正式玩 AI Studio。
iThome鐵人賽
看影片追技術